Using Compile-Time Reflection for Objects’ State Capture1

Checkpointing is a major issue in the design and the implementation of dependable systems, especially for building fault tolerance strategies. Checkpointing a distributed application involves complex algorithms to ensure the consistency of the distributed recovery state of the application. All these algorithms make the assumption that the internal state of the application objects can be obtained easily. However, this is a strong assumption and, in practice, it is not so easy when complex active objects are considered. This is the problem we focus on in our current work. The available solutions to this problem either rely on : § a specific hardware/operating-system/middleware that can provide runtime information about the mapping used between memory and application objects; § a reflective runtime which provides access to class information, such as Java Serialization [1] based on the Java Reflection API; § intervention at the language level, rewriting the original code to add checkpointing mechanisms (e.g. Porch [2] for C programs); § the provision of state handling mechanisms by the user; since the implementation of these mechanisms must be error-free, this is a weak solution. When neither the underlying system nor the language runtime is sufficiently reflective to provide type information about the object classes, the only solution is to obtain this information at the language level. Two approaches can be investigated here: (i) developing a specific compiler (as Porch does) or (ii) using a reflective compiler such as OpenC++ [3] or OpenJava [4]. Since diving into a compiler is very complex and can lead to the introduction of new software faults, we think that the latter is a better solution. Clearly, compile-time reflection opens up the compilation process without impacting the compiler itself. Off-the-shelf compilers can thus be used to produce the runtime entities.